Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added instrumentation of vector TCG operations #38

Merged
merged 62 commits into from
Feb 22, 2024

Conversation

damienmaier
Copy link
Collaborator

This is the code I added for the support of vector TCG instructions in SymQEMU.

I have documented the functions in the source files. There is also some information about the work done in chapter 6 of my bachelor thesis.

@damienmaier
Copy link
Collaborator Author

This PR is built on top of my port to QEMU 8 (#37). It also depends on this PR in SymCC that adds support for creating large symbolic constants.

@sebastianpoeplau
Copy link
Collaborator

I'll wait until we've merged #37 before reviewing this one - the diff should look much nicer after the merge.

@aurelf
Copy link
Member

aurelf commented Feb 6, 2024

@damienmaier could you rebase this branch on the current master?

@damienmaier
Copy link
Collaborator Author

Sure !

@damienmaier
Copy link
Collaborator Author

Just some infos about how files are organized in this PR :

The original sym helper functions are in accel/tcg/tcg-runtime-sym.c.

I put the vector sym helper functions in a new file accel/tcg/tcg-runtime-sym-vec.c. I also created accel/tcg/tcg-runtime-sym-common.c where I moved some code from tcg-runtime-sym.c that is used both for vector and non-vector sym helper functions.

It seemed better to me to have a separate file for vector helper functions, but if your prefer to have everything in accel/tcg/tcg-runtime-sym.c instead, I can change that.

Other that that I modified tcg/tcg-op-vec.c to inject instrumentation TCG ops. I also added support for helper functions with a larger number of arguments as I needed it.

Copy link
Member

@aurelf aurelf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a few comments. It would be nice to clarify those points, if they don't need a change, maybe add a comment on what is needed to to activate those features?

tcg/tcg-op-vec.c Show resolved Hide resolved
tcg/tcg-op-vec.c Show resolved Hide resolved
tcg/tcg-op-vec.c Show resolved Hide resolved
@@ -393,9 +550,9 @@ void tcg_gen_not_vec(unsigned vece, TCGv_vec r, TCGv_vec a)
{
const TCGOpcode *hold_list = tcg_swap_vecop_list(NULL);

if (!TCG_TARGET_HAS_not_vec || !do_op2(vece, r, a, INDEX_op_not_vec)) {
/*if (!TCG_TARGET_HAS_not_vec || !do_op2(vece, r, a, INDEX_op_not_vec)) {*/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as above

tcg/tcg-op-vec.c Show resolved Hide resolved
tcg/tcg-op-vec.c Show resolved Hide resolved
@aurelf
Copy link
Member

aurelf commented Feb 7, 2024

Also it would be nice to merge a PR with your testsuite, before we merge this PR (and you could add the tests that are specific to the vec operations to this PR?)

@damienmaier
Copy link
Collaborator Author

Regarding the commented code, the only motivation was to save implementation time. By making those instructions being systematically replaced by equivalent, already instrumented instructions, I avoided the work of instrumenting them.

For my defense, this trick was already used for several instructions in the original SymQEMU :) Here is an example https://github.com/eurecom-s3/symqemu/blob/master/tcg/tcg-op.c#L1059

I left the original code (but commented) to be consistent, because this is how it was done for other non vec instructions, like in example above.

@damienmaier
Copy link
Collaborator Author

All right, I will make a PR with the tests. I am working on creating a Dockerfile to compile SymQEMU and run the tests

@aurelf
Copy link
Member

aurelf commented Feb 8, 2024

Regarding the commented code, the only motivation was to save implementation time. By making those instructions being systematically replaced by equivalent, already instrumented instructions, I avoided the work of instrumenting them.

Ah, OK. There will be a performance impact I imagine ? The target code could be more efficient if it would be implemented with one instruction ?

For my defense, this trick was already used for several instructions in the original SymQEMU :) Here is an example https://github.com/eurecom-s3/symqemu/blob/master/tcg/tcg-op.c#L1059

Fair :)

I left the original code (but commented) to be consistent, because this is how it was done for other non vec instructions, like in example above.

OK, if my understanding above is correct: could you add a comment, at least on the first such occurrence. I.e., to explain the instruction instrumentation isn't implemented, the alternative works, implementing the instrumentation may give some performance gains (as some likely more effective instructions will be generated)?

Copy link
Collaborator

@sebastianpoeplau sebastianpoeplau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks really good, thank you! I've only added two minor comments related to the discussion that we had in your thesis presentation.

One more minor thing: The README currently says in the "Documentation" section that a large part of the implementation is in tcg-runtime-sym.{c,h} - would you mind adding the vector equivalents there? And do you know whether the test mentioned in the same section still works now that some functions have moved and/or changed signatures?

Comment on lines +366 to +374
* For each element, the concrete result is used to determine if the comparison was true or false,
* and path constraints are pushed accordingly.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you mind also mentioning the alternative of computing a symbolic result vector? It's just an intuition, but I think this will make it easier for the solver to come up with good solutions because path constraints have the problem that changing them often requires multiple iterations.

Comment on lines +439 to +454
* For each element, the concrete result is used to determine if the ternary condition was true or false,
* and path constraints are pushed accordingly.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, let's add the exploration of a symbolic result instead of path constraints as a TODO comment.

@damienmaier
Copy link
Collaborator Author

Ah, OK. There will be a performance impact I imagine ? The target code could be more efficient if it would be implemented with one instruction ?

Yes I think that this has a performance impact.

OK, if my understanding above is correct: could you add a comment, at least on the first such occurrence. I.e., to explain the instruction instrumentation isn't implemented, the alternative works, implementing the instrumentation may give some performance gains (as some likely more effective instructions will be generated)?

I added TODO comments to clarify the the situation

@aurelf
Copy link
Member

aurelf commented Feb 11, 2024

Thanks for the updates !

@damienmaier
Copy link
Collaborator Author

@sebastianpoeplau I added the todos regarding returning expressions instead of pushing path constrains, and I edited the README.

And do you know whether the test mentioned in the same section still works now that some functions have moved and/or changed signatures

I realize now that the way QEMU tests are run has changed between QEMU 4 and QEMU 8, because QEMU now uses meson. I didn't think about those SymQEMU unit tests when I did the port to QEMU 8, so currently the file tests/check-sym-runtime.c is there but I don't know how to run it.

@damienmaier damienmaier marked this pull request as draft February 16, 2024 18:07
@damienmaier damienmaier marked this pull request as ready for review February 16, 2024 18:19
@aurelf
Copy link
Member

aurelf commented Feb 17, 2024

Hi, I rebased this on top of the current main. made a few minor changes, the tests pass.
I think it's good to merge.
It would be nice @damienmaier & @sebastianpoeplau if you could have a look and confirm if it is OK for you?

@damienmaier
Copy link
Collaborator Author

It is ok for me !

@sebastianpoeplau
Copy link
Collaborator

Good for me too!

* Moved check-sym-runtime.c to unit tests and updated to work with QEMU8
* Build and run check-sym-runtime test with meson.build  
* Improve Dockerfile
* Added documentation about test suites
"helper_sym_store_host_i64" and "helper_sym_store_host_i32" were
replaced by helper_sym_store_host, adjusting the unit tests
accordingly
@aurelf
Copy link
Member

aurelf commented Feb 22, 2024

I had to update also the unit tests, which I just re-enabled.
I'll merge now, after the test passes.
Thanks to both of you!

@aurelf aurelf merged commit 5c00e64 into eurecom-s3:master Feb 22, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants